IBIS Macromodel Task Group Meeting date: 08 October 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Altair: * Junesang Lee Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: * Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma * Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak [Kinger Cai] * Chi-te Chen Liwei Zhao Alaeddin Aydiner Sai Zhou Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang * Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Samsung: Jun-Bae Kim Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Signal Edge Solutions Benjamin Dannan Teraspeed Labs: [Bob Ross] Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: Yifan: Draft a new version of BIRD220.1 including language describing the limitations of the approach. - Done. Yifan said she had an update to present. Michael: Check to see if see if Ts4file cross checking code could be donated for use by the ibischk parser. - Done. Michael reported that he had checked the GitHub project he had in mind, but he found that the code was distributed under GPL. He said this licensing scheme would make it difficult to incorporate the code into ibischk or tschk. We would have to make a special inquiry to the authors. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 1st meeting. Michael moved to approve the minutes. Ambrish seconded the motion. There were no objections. -------------- New Discussion: BIRD220.1 update: Yifan noted that she had sent out a new draft of BIRD220.1 that contained language describing the limitations of the approach. She said she was awaiting feedback. Arpad said he had reviewed the draft, and he expressed concern about this sentence: If the pre-drivers have similar on-times, it is recommended to use an equivalent PSIJ for the combined pre-driver stages. Arpad said he thought the results of Yifan's previous investigations had confirmed that the algorithm could not be applied to devices with independent pre-driver stages, even if their delays were similar. Yifan referred to a subsequent sentence noting that the pre-driver PSIJ must be measured under the "same load conditions expected in the application" in order to ensure accuracy. Arpad asked whether a difference in "load conditions" referred only to the load itself or also the V_fixture into which it was driven. Yifan said PSIJ depended upon the load and V_fixture, in the case of independent pre-driver stages. For illustrative purposes, Arpad proposed an example with a capacitive load. He said that at the start of a rising edge, the buffer is in the low state and the capacitor is discharged. As the buffer starts to drive the rising edge, the discharged capacitor effectively looks as though the load is V_fixture = 0V. Once the device is at steady state high, and the capacitor has charged up, the load will look like V_fixture = Vcc when the falling transition begins. So, his fear was that the effective "load conditions" would change. Yifan said she would perform more case studies and investigate. Arpad also requested that the BIRD further explain "DC Jitter Sensitivity" and contrast it with "AC noise". Yifan said that the DC Jitter Sensitivity algorithm can be extended to handle AC power noise by integrating the power rail voltage over time. Arpad asked that the explanations be added in one of the keyword sections, for example Usage Rules, instead of the Definition of the Issue section of the BIRD, which does not become part of the specification. Ts4file and [Ramp]: The group continued the previous discussions, and Michael focused on the table Walter had created enumerating the combinations of I-V, V-t, Ts4file, and External Model and their interactions with [Ramp]. Michael noted that Walter had updated the table during/after the previous meeting. Michael summarized the discussions regarding the parser cross checking [Ramp] information. He said we all agree the cross checking anything against [External Model] is beyond the scope of the parser. However, should we implement the missing checks of [Ramp] against other data (Ts4file, V-t waveforms)? Michael noted that Arpad had proposed adding additional loading information variations to the [Ramp] keyword, so it could be cross checked against the V-t waveforms. Arpad noted that he and Walter had preferred to keep [Ramp] as a required keyword. Ambrish said he did not. He said IBIS had always progressed with the idea that a new keyword might not be supported yet by a particular tool, so we keep a valid [Ramp] around for tools that don't support the newer keywords. He said that was originally done when V-t waveforms were added, and the same thing was done when [External Model] was added. He said we could do the same thing for Ts4file, knowing full well that [Ramp] information isn't needed in a Ts4file simulation. Walter said we ignore [Ramp] for the purposes of the actual simulation in a Ts4file case, but [Ramp] is still useful to EDA tools for other purposes. Arpad said Ts4file is itself a special case. While [External Model] is clearly intended to replace the contents of the legacy analog keywords, the Ts4file section says Ts4file is "intended exclusively for AMI applications." If that is the case, then the [Model] must be able to provide other information for non-AMI simulations. Since the Ts4file section recommends [External Model] for the purposes of non-AMI simulation, and [External Model] replaces the legacy keywords, we might then arrive at the conclusion that legacy keywords should be ignored in Ts4file models. But it takes two steps to arrive at that conclusion and isn't explicitly stated. In addition, Arpad said one limitation of Ts4file 4-port data models is that they aren't useful for power integrity simulations. Therefore, it's not enough to just wrap a Ts4file in an [External Model] and say it's sufficient for non-AMI purposes. Ambrish said all of those arguments were valid back when Ts4file was introduced and added to the .ami file. He said we casually put this aspect of the channel characterization in the .ami file, and we knew then that there would be many simulations that needed nothing from the .ibs file. We should have put this Ts4file information in the .ibs file back then. Arpad agreed, but he said we've gained some new insights in the ten years since that was done. Michael said the question remains, should we remove the requirement for [Ramp], or should we consider adding new cross checks if we keep it? Ambrish said he felt it should not be required. Walter and Arpad preferred to keep [Ramp] as a required keyword. Walter said even when [Ramp] data isn't used in the actual simulation, it provides useful information to the simulator for time stepping. Curtis said he preferred to keep the [Ramp] requirement, but he said Ambrish's recollection was historically accurate. He said Ambrish had originally expressed concern about putting the Ts4file in the .ami file as a parameter. He agreed with Ambrish that some of these new complications arise from the fact that we're now contemplating [Model]s that violate the original spirit of "intended exclusively for AMI applications" and the recommendation that [External Model] be used to provide comparable information for non-AMI simulations. Walter said he was okay with adding additional cross checks, but he asked why we would do it. He said the different keywords represent two different behaviors. If you have I-V curves and C_comp, you can't handle reflections. That's why Ts4file was important. Models are for making engineering decisions. Sometimes Ts4file is the best choice for making a decision, sometimes it's not. Arpad said that's true, but the checking is also for the model maker. We want to alert the model maker to any discrepancies with a warning, not an error. You wouldn't want a model that gave 2x or 3x the amplitude or edge rate depending on which keyword you used. Michael said he thought he had some direction for his next draft BIRD update. He said he would not change the [Ramp] requirement, but he would add some new text clarifying the cross checks. He said he might revisit the [External Model] text as well. - Michael: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. New ARs: Yifan: Perform additional investigations into the applicability of BIRD220.1 for devices with independent pre-driver stages. Michael: Prepare a new draft BIRD updating the language surrounding Ts4file and Ramp and related cross checking. ------------- Next meeting: 15 October 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives